1. Field of the Invention
The invention relates to a configuration device for the graphical creation of at least one test sequence for controlling a test device having at least one electronic computer unit, whereby the test device can be controlled according to the created test sequence, whereby the configuration device has at least one display device, graphical library functional elements being displayed with the display device in a library field, whereby the test sequence can be created by placing at least one instance of a library functional element in a configuration field, whereby the instance of a library functional element, said instance being placed in the configuration field, references the library functional element itself.
2. Description of the Background Art
Configuration devices are known from the conventional art and are used as a technical tool in order to selectively address and control a test device (e.g., “AutomationDesk 3.2, Test and Experiment Software”, Product Description, dSPACE 2011). The test device typically is a high-performance simulation computer, which often has a number of electronic computer units and assigned I/O devices, whereby a device-under-test, such as, e.g., a control device, is connected to the test device; this corresponds to a typical structure of a hardware-in-the-loop system.
The test sequence is a selective control of the test device and the I/O components typically comprising the test device, so that the device-under-test connected to the test device is supplied with specific signals. The response of the device-under-test to the stimulation is then also determined with the test device with the use of measurement techniques and compared with the expected behavior, so that it can be determined whether the device-under-test behaves as desired. Frequently, the test device is equipped with a real-time-capable operating system, so that the time response of the test sequence can also be predefined and the time response of the connected device-under-test can be evaluated.
As in other fields, graphical programming has proven extremely useful for the creation of test sequences as well, whereby this is understood to be the description of the test sequence by block diagrams. The sequence of test events is described by a series of functional elements depicted as blocks.
The configuration device can be implemented in a computer different from the test device and be connected to the test device only via a data connection. It is then possible that the created test sequence is carried out in the configuration device itself and the test device is provided only with corresponding instructions for carrying out the test sequence. It is possible equally well that the graphically created test sequence is converted into an executable program with the aid of the configuration device and this program is run on the test device. It is also possible that the configuration device and the test device coincide in terms of equipment; the precise device-related configuration is not relevant in the present case. Configuration devices known from the state of the art typically have a basic configuration of functions, which can be used during the creation of a test sequence; this basic configuration consists of libraries of graphical functional elements. Examples of such library functional elements are a loop functionality (for/while) or a conditional functionality (if-then-else); also important are corresponding library functional elements, which represent the test device, so that the test device is accessible in terms of hardware via the test sequence.
The aforementioned libraries are not necessarily predefined; such libraries can also be created by the user of the configuration device.
In the graphical creation of a test sequence, the typical approach is to select a graphical library functional element from a library shown in a library field and to place the selected graphical library functional element in a configuration field (“drag-and-drop”). The library functional element placed in the configuration field is not the library functional element of the library itself, but an instance of the graphical library functional element, whereby this instance is connected to the library functional element, in other words, references the library functional element. This means that a subsequent change in the library functional element within the library also has an effect on the instances of this graphical library functional element in the test sequence in which instances of the library functional element are used.
When the instance of a library functional element is to be changed within a test sequence, then this is only possible in that the reference to the library functional element is no longer used and the test sequence receives a copy of the library functional element instead of the reference in the library. In fact, this (modified) copy of the functional element can then be defined again as a library functional element, but this has the consequence that the functional element libraries increase constantly, even if only minor variations of existing functional elements are created. It is disadvantageous here that desired changes of a basic functionality, which is the same in all functional elements, either must occur locally in different test sequences, when there is no longer a reference to the library element, or, the change must be made in each different version of the library functional element, which is also work-intensive.
The work with possibly only very slightly different versions of a library functional element or of copies of these functional elements in test sequences can be worked around in the state of the art only in that a comprehensive library functional element covers all existing versions, whereby there is the risk, however, that a poorly understandable functional structure arises, which contains a complicated case control for the differentiation and selective activation of function modifications.